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SC and IP work together to 
identify parameters of 
authorization service. 
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SC and IP work together to 
identify customer and 
employee information 
needed to respond to an 
authorization request. 
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SC and IP work together to 
define a credential-record 
format for storing categories 
of information. 
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SC and IP work together to 
identify any additional 
information necessary to 
respond to authorization 
request. 
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SC and IP work together to 
create a messaging 
specification. 
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SC and IP work together to 
define implementation rules. 



306 



IP presents the proposed 
authorization service to a 
policy management 
authority at Root. 
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Root-entity policy J 
management authority 
reviews proposed service. 
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Does Root-entity policy 
management Authority 
approve proposed service? 
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Root-entity policy 
management authority 
notifies IP. 
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Root stores messaging 

specification and 
implementation rules in 
central repository and 
notifies IP. 



310 



IP stores approved 
messaging specification and 
implementation rules in 
directory and notifies SC. 
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SC supplies attribute 
information to populate 
credential records for SC's 
employees. 
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IP establishes a credential 
record for each employee of 

SC. 
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IP stores credential records 
in directory. 
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John Smith (JS) visits Web J~ 
site of XYZ Co. (XYZ). 



401 



XYZ Web server 
communicates data to be 
digitally signed to JS's 
browser. 



Data to be signed is 
forwarded to smartcard 
which signs the data to 
create digitally-signed 
document. 
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JS's browser receives 
digitally-signed document 
and transmits it to XYZ's 
Web server. 
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Go to step 
416 



XYZ receives digitally-signed 
document 



XYZ decide to check whether 
JS authorized to sign data 
(e.g., purchase order) 



XYZ generates request for 
appropriate authorization 
request format, signs the 
request and sends it to Bank B. 
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Yes 


XYZ determines whether it has 
appropriate message format for 
desired authorization request 
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Bank B forwards the 
request to root entity 



IT 



409 



Go to step 
414 



Root entity receives the request 
and retrieves from central 
repository access control 
implementation rules for the 
service identified in the request 
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Root entity applies the access 
control implementation rules to 
Yes determine whether or not XYZ 
is authorized to receive the 
requested authorization request 
message format 
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No 



Root entity generates rejection C 
message, signs it, and ^ 
sends it to Bank B. 
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Bank B forwards rejection 
message to XYZ 
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Root retrieves from central 
repository requested 
authorization request message 
format, signs message including 
format, and forwards 
message to Bank B. 



414 



1 




Bank B forwards 
message to XYZ 
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XYZ use authorization request 
message format to generate 
authorization request 
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XYZ signs authorization 
request message and 
send it to Bank B 
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Bank B forwards authorization 
request to Bank A 
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Go to step 
428 





Bank A receives request, 


! Yes 


checks repository for 




appropriate messaging 




specification data 
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419 



Bank A generates a request for 
this data, signs it, and sends it 
to root entity 



420 



FIG. 4E 



Inventors: Tallent et al. 
Serial No.: 09/950,059 
Atty. Docket: 20068170-0091-002 

Replacement Sheet 12 of 21 j 



Root receives the request and 
retrieves from central repository 

any applicable access-control 
implementation rules necessary 
to process the request 
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Go to step 
426 



Yes 



Root applies access control 
implementation rules to 
determine whether or not it will 
release requested message 
format 
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422 



No 



Root generates a rejection C 
message, signs it, and ^ 
forwards it to Bank A 
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Bank A generates a message 
indicating that it cannot process 
the authorization request, signs 
it, and forwards it to Bank B 
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Bank B forwards 
message to XYZ 


1 





Root retrieves from central 
repository requested 
authorization response 
message format, signs 
message including format, 
forwards it to Bank A 
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426 



Bank A retrieves from directory 
credential record for individual 

that is the subject of the 
authorization request and any 
necessary definitions and 
mapping 
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Bank A generates 
authorization response 
message 
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Bank A signs the 
authorization response 
message and sends 
it to Bank B 



Go to step 
432 



Not 
Satisfactory 



Bank B transmits 
authorization response 
message to XYZ 



Satisfactory 



429 



430 



XYZ sends confirmation 
message to JS 
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XYZ sends message to JS _) 
disaffirming the transaction 
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SC visits RC's Web site 
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RC's Web server 
communicates data to be 
digitally-signed to SC's 
browser 
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Data to be signed is 
forwarded to SC's smart 
card which signs the data to 
create a digitally-signed 
document 
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SC's browser receives 
digitally-signed document 
and transmits it to RC's Web 

server 
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RC receives digitally-signed ^ 
document 
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RC generates an authorization J~ 
request message 
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RC creates an OCSP request ^ 
for SC's certificate 
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RC concatenates the two 
requests and signs the resulting 

message 
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RC transmits request(s) to RP 
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RP identifies IP that issued 
certificate that is subject of 
OCSP request 
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RP forwards the request to IP 






IP processes 
authorization request 



611 



r 



612 



FIG. 6C 



Inventors: Tallent et al. 
Serial No.: 09/950,059 
Arty. Docket: 20068170-0091-002 
Replacement Sheet 19 of 2 1 



IP create OCSP response for 
validation request 



613 



IP concatenates authorization 
response and OCSP response 
and signs the resulting 
message 
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IP transmits response(s) 
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Go to step 
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Satisfactory 



RC reviews the responses 
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RC may send message to SC 
disaffirming the transaction 



619 



FIG. 6E 



Inventors: Tallent et al. 
Serial No.: 09/950,059 
Arty. Docket: 20068170-0091-002 
Replacement Sheet 21 of 21 



102 



BANK 



ii ii ii ir 



" ' 



" " II 




I | | ii ii it 



ISSUING 
PARTICIPANT 




110 



ROOT ENTITY 



104 



BANK 



■' " " " 



I 



■■ " ■! 




i || ii ii ii 



RELYING 
PARTICIPANT 



106 





SUBSCRIBING 
CUSTOMER 




RELYING 
CUSTOMER 



FIG. 7 



